home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 9760 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.7 KB
  1. Path: news.gate.net!not-for-mail
  2. From: dhaire@gate.net (doug haire)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Is USR going to support 42bis+ on future courier upgrades?
  5. Date: 31 Mar 1996 05:37:14 -0500
  6. Organization: CyberGate, Inc.
  7. Message-ID: <4jln8q$2456@seminole.gate.net>
  8. References: <4j2fv1$8kf@nnrp1.news.primenet.com> <4j2iun$a3t@newsbf02.news.aol.com> <4j3r1f$1tc4@seminole.gate.net> <199603250259.TAA29106@usr4.primenet.com> <Pine.A32.3.91.960324221226.65344C-100000@seminole.gate.net> <199603260039.RAA13361@usr1.primenet.com> <Pine.A32.3.91.960326013850.75314E-100000@navajo.gate.net> <199603270509.WAA02851@usr2.primenet.com> <Pine.A32.3.91.960327001856.32608A-100000@seminole.gate.net> <4ji02l$ibg@nnrp1.news.primenet.com>:
  9. NNTP-Posting-Host: seminole.gate.net
  10. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  11.  
  12. Bob Nixon (bigrex@primenet.com) wrote:
  13. : No HS link, This was all TCP/IP(PPP) with two occurances of WS-FTP32 set 
  14. : to the same place(my home directory at my internet provider). Send the 
  15. : file in, rename it then send it back and as quick as I can click the mouse 
  16. : key send the original "IN" back in too. Same file transfering in oposite 
  17. : directions except that one has been renamed. This is actually a little 
  18. : slower than your proposed HS-Link or s-modem due to greater TCPIP 
  19. : overhead, reliance on the hosts buffering and disk access load and finally 
  20. : and probably the least significant is my own computers disk buffering of 
  21. : the two files. This was also done during my ISP's peak load time or about 
  22. : 9:30PM on a week night.
  23. : 
  24. : You've also IMO been reading too much negitive crap about WIN-95. 
  25. : Althought it strickly speaking loads the DOS 7 kernel in first according 
  26. : to MS anyway, the code loaded after that is 32bit. The DOS 7 kernel is 
  27. : retained for backward compatibility.
  28. : 
  29.  
  30. I'm not going to continue to argue with you. You aren't going to be 
  31. convinced and I don't wish to further waste my time.
  32.  
  33. I know what I experienced, I know what I tested. I asked you to do the 
  34. same. Believe whatever you wish.
  35.  
  36. : In article <Pine.A32.3.91.960327001856.32608A-100000@seminole.gate.net>, 
  37. : dhaire@gate.net says...
  38. : >
  39. : >On Tue, 26 Mar 1996, Bob Nixon wrote:
  40. : >
  41. : >> Appology accepted, I admittedly don't understand the inner workings of 
  42. : how 
  43. : >> Win-95 handles the com ports or if the DTE settings above 115200 are 
  44. : real 
  45. : >> but concerning the mutitasking while moving files both in and out plus 
  46. : >> Bi-directional transfers here are my nunbers for single and 
  47. : by-directional 
  48. : >> transfers of highly compressable files while running a DOS graphics 
  49. : based 
  50. : >> game running in demo mode in the background. My system is AMD486DX4-120 
  51. : >> w/32megs of ram and Diamonds Stealth-32 graphics card. The modem is USR 
  52. : >> Courier with V.34+ code. Tranfers for single or one way file transfer 
  53. : of a 
  54. : >> Coreldraw.cdr(border file) 10600cps both inbound and outbound with a 
  55. : >> 28800/28800 connection. Bidirections transfer slowed to about 8000cps 
  56. : on 
  57. : >> each direction. Both these numbers are nearly identical to the speeds 
  58. : that 
  59. : >> I've gotten on previous tests. BTW transfer method was WS-FTP32 with a 
  60. : >> Win-95 ppp connection to my ISP, Primenet in Phoenix, AZ at 9:30PM(busy 
  61. : >> prime hours) to my home directory.
  62. : >> 
  63. : >> PS. Comm overruns were not observed during any testing.
  64. : >
  65. : >Ok, let me try to explain what's going on here. First, the modems between 
  66. : >the computers are controlling the transfer in conjunction with the CPU's 
  67. : >at each end. In addition, the 115200 DTE rate is bottle-necked down to 
  68. : >28800 between the modems. This is true even though the throughput rate is 
  69. : >above 10600 cps. Why? you might ask. Well, the modems compress the data 
  70. : >first *before* sending it. This also helps explain why the throughput 
  71. : >in each direction drops when doing bi-directional transfers on 
  72. : >uncompressed files; the modems each are doing double-duty compressing and 
  73. : >uncompressing each data stream.
  74. : >
  75. : >Your numbers pretty much match mine on modem to modem transfers both in 
  76. : >uni-directional and bi-directional transfers. I presume you used HS/Link 
  77. : >for the bi-directional (and, from the rates on uni-directional, probably 
  78. : >on those also)? I need to try this with Smodem (in my opinion, a more 
  79. : >efficient and fault-free bi-directional protocol) and see what I get on a 
  80. : >bi-directional transfer with that.
  81. : >
  82. : >Now, if you have two computers, hook up a null modem cable between them 
  83. : >and open each port at 115200. Take a file and transfer it. That was my 
  84. : >bench test for comparison between the linux and DOS platforms. No modems, 
  85. : >no LapLink, just two comm programs (Commo on one side and minicom on the 
  86. : >other) using zmodem (DSZ at one end, the built-in zmodem at the other)
  87. : >I would be interested to see results of a 230k port setting at each end 
  88. : >with DOS or Win95 at each end also.
  89. : >
  90. : >The tests were made in one direction only; from the DOS box to the 
  91. : >linux/DOS box, with the linux/DOS box booted to DOS and then booted to 
  92. : >linux. When the linux/DOS box was in DOS, the comm program was Commo 
  93. : >w/DSZ as the zmodem protocol drive (also did it with DSZ as a 
  94. : standalone).
  95. : >
  96. : >Again, I am not using Win95 but I do know a little about that platform. 
  97. : >It isn't really a true operating system, it runs on DOS 7.0 so it's 
  98. : >subject to similar problems that any DOS box might have. It is, I am 
  99. : >informed, much improved over Windows 3.1 (and WFWG 3.11) but I still see 
  100. : >complaints about throughput and overruns.
  101. : >
  102. : >What amazed me about linux was the absolute lack of errors during a true 
  103. : >hi-speed transfer (115200 from end to end). I was used to limiting the
  104. : >DOS-to-DOS connections to 57600 in order to limit the errors during 
  105. : transfer.
  106. : >
  107. : 
  108.